Fargate1.4.0のアーキテクチャ変更によりコンテナ実行スピードに変化はあるのか検証してみた!

Fargate1.4.0のアーキテクチャ変更によりコンテナ実行スピードに変化はあるのか検証してみた!

Clock Icon2020.05.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは(U・ω・U)
AWS事業部の深澤です。

皆さん、Fargate1.4.0のリリースから約2ヶ月が経とうとしておりますが導入は検討されていますでしょうか。今回のリリースにより従来の1.3.0と比較し本当に多くの機能が利用できるようになりました。できるようになった機能一覧は弊社島川のブログが大変わかりやすいので是非ご参照下さい。

さて実はこうしていろんな機能が利用できるようになった背景には、アーキテクチャの変更が大きく関わっています。詳しくは以下のAWS公式のブログが大変参考になります。

端的にまとめますと、コンテナの管理にDocker Engineを使っていましたが、1.4.0からはContainerdに切り替わったり、コンテナエージェントがECSエージェントからFargateの独自エージェントに変わったりしました。これだけアーキテクチャに大きな変更が加わると、コンテナの実行速度にも影響が出ているのではと気になりますよね。そこで今回は1.3.0と1.4.0でどのくらいコンテナの実行速度が変わったかを調べてみました!

検証方法

実行速度の評価定義ですが、スクリプトをコンテナに入れてそれを実行できるまでの時間と今回は定義します。RunTaskは自分のローカルPCから実行します。スクリプトの言語にはpythonを用いてシンプルに処理を記述します。

import logging


def main():
    logging.basicConfig(level=logging.INFO, format='%(asctime)s %(levelname)s %(name)s :%(message)s')
    logger = logging.getLogger(__name__)
    logger.setLevel(logging.DEBUG)
    logger.info('Fargate起動')

if __name__ == "__main__":
    main()

このlogger.info('Fargate起動')が出るまでの時間で評価します。続いてDockerにはalpineを用いて次のようなDockerfileを定義しました。

FROM python:3.8.3-alpine
COPY main.py /app/
WORKDIR /app

単純に上記のpythonファイルを入れているだけです。

環境用意

ECRの作成とFargateクラスターの作成方法については今回割愛させて下さい。タスク定義は以下のようにしました。

{
    "family": "fargate-platform-agility-test",
    "networkMode": "awsvpc",
    "containerDefinitions": [
        {
            "name": "fargate-platform-agility-test",
            "image": "12345678910.dkr.ecr.ap-northeast-1.amazonaws.com/fargate-platform-agility-test:latest",
            "memory": 512,
            "cpu": 256,
            "workingDirectory": "/app",
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "fargate-runtask-app-logs",
                    "awslogs-region": "ap-northeast-1",
                    "awslogs-stream-prefix": "fargate-platform-agility-test"
                }
            }
        }
    ],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "cpu": "256",
    "memory": "512",
    "executionRoleArn": "arn:aws:iam::12345678910:role/ecsTaskExecutionRole"
}

これを以下のようなRunTaskコマンドで実行します。

aws ecs run-task \
    --task-definition fargate-platform-agility-test:1 \
    --cluster practice-fargate-cluster \
    --network-configuration file://network_configuration.json \
    --launch-type FARGATE \
    --overrides file://container_overrides.json \
    --platform-version 1.4.0 \
    --count 1

このplatform-versionを切り替えることで1.4.0と1.3.0の切り替えを行います。なおcontainer_overrides.jsonには実行コマンドの上書きだけ入れてあります。

{
    "containerOverrides": [
        {
            "name": "fargate-platform-agility-test",
            "command": [
                "python",
                "main.py"
            ]
        }
    ]
}

検証!

さて微妙な差が出るかもしれないので、それぞれ5回実行しました。結果は以下のようになりました。

1.4.0

回数 実行にかかった時間(秒)
1回目 22
2回目 20
3回目 15
4回目 19
5回目 26

平均にすると20秒です。

1.3.0

回数 実行にかかった時間(秒)
1回目 23
2回目 16
3回目 18
4回目 22
5回目 24

平均にすると20.6秒です。

結果

0.6秒の差なので1.4.0のほうが実行スピードが速いと評価するのはかなり微妙な気がします。ネットワークのレイテンシとかでも全然発生しうる差だと思いますし、そのほかのわずかなオーバーヘッドでも発生しそうな差だと思います。

最後に

いかがでしたでしょうか!実行スピードという観点だと1.3.0も素晴らしいですね。ちなみに本記事執筆時点(2020年5月29日)で、プラットフォームバージョンにLATESTを指定すると1.3.0になります。

なので安定版という観点だと1.3.0だと思います。ですが、初めにご紹介した通り1.4.0では多くの機能が利用できるようになっています。現時点で1.3.0で運用されていて1.4.0に切り替えをご検討されている場合は慎重な判断を求められるかもしれませんが、もしこれからFargateを導入されるという方は1.4.0にトライしてみてはいかがでしょうか。

以上、深澤(@shun_quartet)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.